TLS: Allow specification of both typed and non-typed san matchers in config#20529
TLS: Allow specification of both typed and non-typed san matchers in config#20529ggreenway merged 11 commits intoenvoyproxy:mainfrom
Conversation
are provided in config. Signed-off-by: Pradeep Rao <pcrao@google.com>
Signed-off-by: Pradeep Rao <pcrao@google.com>
|
/assign adisuissa |
|
Just curious if we can back port this to v1.21 ? |
Yes! |
|
Assigning Greg who also reviewed the original PR (#18628). |
| subject_alt_name_matchers(config.match_typed_subject_alt_names().begin(), | ||
| config.match_typed_subject_alt_names().end()); | ||
| // If typed subject alt name matchers are provided in the config, don't check | ||
| // for the deprecated non-typed field. |
There was a problem hiding this comment.
This is minor behavior change we should add to release note I think?
There was a problem hiding this comment.
There was a problem hiding this comment.
Done. Could you please take a look?
| const envoy::extensions::transport_sockets::tls::v3::CertificateValidationContext& config) { | ||
| if (!config.match_typed_subject_alt_names().empty() && | ||
| !config.match_subject_alt_names().empty()) { | ||
| throw EnvoyException("SAN-based verification using both match_typed_subject_alt_names and " |
There was a problem hiding this comment.
should we keep a warning message for the user? since we ignore this quietly, the user won't know the match_subject_alt_names was ignored.
Signed-off-by: Pradeep Rao <pcrao@google.com>
Signed-off-by: Pradeep Rao <pcrao@google.com>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
|
LGTM except the doc need to be fixed. |
|
PTAL at CI |
Signed-off-by: Pradeep Rao <pcrao@google.com>
Signed-off-by: Pradeep Rao <pcrao@google.com>
Signed-off-by: Pradeep Rao <pcrao@google.com>
|
The windows only failure (https://dev.azure.com/cncf/envoy/_build/results?buildId=104855&view=logs&j=b840a642-5ff3-5357-2e4b-e06e40b0cffd&t=67965174-5100-5631-9dc0-68b9f0aacb53&l=3085) seems to be unrelated to my changes. Will try retesting. |
|
/retest |
|
Retrying Azure Pipelines: |
|
/retest |
|
Retrying Azure Pipelines: |
Hi Greg, this was the only one I could find: envoy/api/envoy/config/core/v3/base.proto Line 249 in f9d936e (note that filter_metadata is not yet deprecated, but the plan is to deprecate it soon as per @yanjunxiang-google) |
|
@envoyproxy/api-shepherds can you comment on if this the correct way to handle this from an API perspective? If there's nothing unique about this situation, how has this been handled for other similar issues? /wait-any |
Signed-off-by: Pradeep Rao <pcrao@google.com>
|
/retest |
|
Retrying Azure Pipelines: |
|
@ggreenway I think this is a common pattern (introduce new field which is effectively oneof, prefer one over the other), but there are also places where you see both fields continuing to be used, e.g. verify_certificate_{spki,hash}. I think as long as you can set both, and prefer the most correct/safest/etc, you enable safe rollouts. |
ggreenway
left a comment
There was a problem hiding this comment.
Code looks good; release notes have issues.
/wait
| ---------------------- | ||
| *Changes that may cause incompatibilities for some users, but should not for most* | ||
|
|
||
| * access_log: log all header values in the grpc access log. |
There was a problem hiding this comment.
Something went wrong here; I think you picked up a bunch of entries during a bad merge or something.
| * sip-proxy: add customized affinity support by adding :ref:`tra_service_config <envoy_v3_api_msg_extensions.filters.network.sip_proxy.tra.v3alpha.TraServiceConfig>` and :ref:`customized_affinity <envoy_v3_api_msg_extensions.filters.network.sip_proxy.v3alpha.CustomizedAffinity>`. | ||
| * sip-proxy: add support for the ``503`` response code. When there is something wrong occurred, send ``503 Service Unavailable`` back to downstream. | ||
| * stateful session http filter: only enable cookie based session state when request path matches the configured cookie path. | ||
| * tls: if both :ref:`match_subject_alt_names <envoy_v3_api_field_extensions.transport_sockets.tls.v3.CertificateValidationContext.match_subject_alt_names>` and :ref:`match_typed_subject_alt_names <envoy_v3_api_field_extensions.transport_sockets.tls.v3.CertificateValidationContext.match_typed_subject_alt_names>` are specified, the former (deprecated) field is ignored. |
There was a problem hiding this comment.
Please note the previous behavior (that this was an error).
There was a problem hiding this comment.
New text looks good, but you're still adding 50 entries to the release notes. Please fix.
There was a problem hiding this comment.
Sorry, missed that. Must've have happened because of the 1.22 release. Done now.
Signed-off-by: Pradeep Rao <pcrao@google.com>
Signed-off-by: Pradeep Rao <pcrao@google.com>
|
/retest |
|
Retrying Azure Pipelines: |
adisuissa
left a comment
There was a problem hiding this comment.
LGTM, thanks!
/lgtm api
|
@ggreenway Do I have your approval to backport this to 1.21 and 1.22? |
…config (envoyproxy#20529) Allow configs with both typed and non typed san matchers specified to allow config servers to use the same config for Envoys across multiple versions. The match_subject_alt_names field is ignored if match_typed_subject_alt_names is set. Signed-off-by: Pradeep Rao <pcrao@google.com>
Commit Message:
Additional Description:
Allow configs with both typed and non typed san matchers specified to allow config servers to use the same config for Envoys across multiple versions. The match_subject_alt_names field is ignored if match_typed_subject_alt_names is set.
Risk Level: Low
Testing: Modified test, ran //test/...
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A